Many computer software applications operate through a visual interface. Such applications produce one or more views that can be displayed in windows on a computer screen. During operation, a user sometimes wishes to have a new view displayed. Some new views can be displayed in the active application, while some require that a different application be launched. Moreover, the act of causing a new view to be displayed occurs in many different contexts, such as in the use of hyperlinks, clicking on a navigation button in a portal, typing a page address into an address field, and in clicking on the “back” button of a browser.
The linking from a present view to a new view currently has some shortcomings. For example, some computer applications require the user to close a transaction that the user has started in a view before beginning a new transaction. As a result, the user cannot navigate to a new view without closing the current transaction, and must decide whether to save modified data before doing so. This is disadvantageous in some cases, for example where the user needs additional data while filling out information in one application. Sometimes, in these cases, the user must close or leave the first application, obtain the necessary data from a second application, and then restart or return to the first application.
Also, many current online computer applications have stateless user interfaces that recreate the same view whenever they are activated. One example is form-based ordering or reservation services offered on the World Wide Web (“the web”). Typically, the user is asked to enter information in the form as part of an application process, and the information is transmitted to the server when the user clicks a “submit” button after filling out the form.
In some cases, the stateless application loses the information entered by the user if the user navigates to a different web page. This may happen when the user clicks on a hyperlink to navigate to a different web page, or when the user activates the “back” button on the web browser after making changes in the form. If the user wishes to resume filling out the form, it becomes necessary to re-enter the information that was lost during the navigation. This delays completion of the form and increases the risk for user mistakes.
The difficulties associated with exiting, and then returning to, a modified page have limited the efficiency and flexibility of computer networks. For example, users often need additional information when filling out an online form. In many cases, such information is available over the computer (through an internal network or the internet), but linking to such a view in the same window typically leads to loss of entered or changed data in the present view.
Attempts have been made to overcome this problem by having the application store information on the user's computer, typically the “client” in a client-server network. The state of the displayed form has been stored as a “cookie” (a resident file on the client computer). If the user navigates to a different view after filling out data in the form and later returns to the form view, the application may be able to use the cookie for restoring at least some of the lost information.
However, using cookies has several disadvantages. The solution is application specific and can require unique programming for each application to work. Even with custom programming, the cookie only holds a limited amount of information. Accordingly, the method is difficult to make generally applicable, and is unsuitable for applications that use large amounts of data.
On the other hand, it is impractical for a browser to always open a separate window when navigating to a new view. After navigating through a number of links, the windows on the screen may become so many that it is difficult to distinguish them, and having a great number of open windows may also unnecessarily burden the system.